The following background discussion includes information that may be useful in understanding the present invention. It is not an admission that any of the information provided herein is prior art or relevant to the presently claimed invention, or that any publication specifically or implicitly referenced is prior art.
Flooding Denial-of-Service (DoS) attack or a distributed variant of it called Distributed DoS (DDoS) attack is one of the most disastrous security threats that the Internet is facing today. Though such attacks are not new on the Internet, they have been gaining significant momentum and sophistication during the past three decades. Noticeably, some of the most powerful flooding attacks reported in year 2010 and 2011 involved traffic rates of 100 Gbps and 60 Gbps respectively. If the Internet access link of a target network is bombarded with such a huge magnitude of flood, the entire target network can be virtually detached from the Internet through traffic jamming. This will eventually create a complete denial-of-service scenario by blocking the movement of any legitimate traffic between the target network and the Internet. Apart from imposing a complete DoS scenario to the target network, malicious traffic of huge magnitude can also destabilize the operation of a larger part of the connected upstream network including the Internet.
Most of the sophistication in flooding DoS attacks is centered on flood generation strategy. As a prior step towards launching a conventional brute-force flooding DoS attack, the attacker first compromises vulnerable computers on the Internet and install attack program. The compromised computer running a malicious program is called a bot or zombie, and a network of several such bots under the control of the attacker is called botnet. The attacker instructs the botnet to generate and direct the flood traffic to the victim on behalf of the attacker. The flood typically consists of large number of routable Internet Protocol (IP) datagram with each containing a TCP (Transmission Control Protocol) or UDP (User Datagram Protocol) segment at the payload field of the IP datagram. Thus, as far as protocol syntax and semantic are concerned, flood packets are identical to any other TCP/IP packets traversing through the Internet and this in turn make it difficult to differentiate flood from genuine traffic.
Though botnet based approaches have been very effective for powerful DoS flood generation in the past, their future success will mainly depend on the continued availability of substantial number of compromised computers to form the botnet infrastructure. Recent prior arts have disclosed a number of systems, methods and apparatus to detect, track and rescue botnets in real time. For complete details of these prior arts, reference may be made to US patent application No. US20110154492 A1 entitled “Malicious traffic isolation system and method using botnet information” dated June 2012, US patent application No. US20120054869 A1 entitled “Method and apparatus for detecting botnets” dated March 2012, and U.S. Pat. No. 8,195,750 B1 entitled “Method and system for tracking botnets” dated June 2012, wherein widespread implementation and deployment of some of the techniques disclosed through the above referred prior arts might force the adversaries to explore more tactical flood generation strategy.
An alternate and more sophisticated flood generation strategy has gained attention in the recent past. In this case, instead of using compromised computers on the Internet for flood generation, standard features of communication protocol stack on remote computers are tactically exploited to force them to eject DoS flood. In this approach, the remote computer need not be compromised and no attack program needs to be explicitly installed or executed on it for flood generation. One such scenario was recently demonstrated in Stream Control Transmission Protocol (SCTP), a relatively new and highly promising transport layer protocol standardized by IETF (Internet Engineering Task Force). Reference may be made to IETF RFC 4960 “Stream Control Transmission Protocol”, wherein complete specification of the SCTP is documented. In particular, reference may be made to the prior art entitled “Finding Protocol Manipulation Attacks” by authors Nupur Kothari et al. published in proceedings of ACM SIGCOMM-2011, Toronto wherein the authors have revealed that a greedy SCTP receiver can download files from a standard SCTP sender faster than genuine SCTP receivers through a technique called optimistic SACK (Selective Acknowledgement) spoofing. While this is an undesirable scenario leading to unfairness among competing SCTP flows, reference may be made to another prior art entitled “Feedback Manipulation Flood Attacks: Feasibility Evaluation and Impact Quantification on Stream Control Transmission protocol” by authors V. A. Kumar and D. Das published in the proceedings of ICITST-2012, London wherein the real potential of optimistic SACK spoofing for powerful and sustained DoS flood generation was systematically demonstrated through simulation and real-world experimentations. This is a next generation flooding strategy, which if practiced will have a huge security impact on the Internet.
It is important to highlight that though TCP continues to be the dominant connection oriented transport layer protocol on the Internet, SCTP is gaining popularity and emerging as a potential alternate to TCP. Today, SCTP is being deployed on the Internet because of its unique features such as multi-homing, multi-streaming, ability to preserve message boundaries, inbuilt protection against SYN-flood like attacks etc., which are not available in TCP. Most of the current generation public domain and commercial operating systems include SCTP as an integral part of the kernel along with socket API (Application Programming Interface) for application development. Though limited, there exist a number of client-server applications functional over SCTP including prototype implementations of Apache web server and Firefox web browser. SCTP has also demonstrated promising results as a transport layer protocol for transporting MPI (Message Passing Interface) messages in supercomputers involving massively parallel and densely interconnected hardware.
SCTP is considered as a next generation transport layer protocol on the Internet and more and more services that are currently available over TCP are expected to be migrated to SCTP in the near future. It is further important to highlight that optimistic SACK spoofing is not arising from any implementation flaws in SCTP, rather it originates from the protocol specification. Mere existence of standard implementation of SCTP servers is the only pre-requirement for launching optimistic SACK spoofing based attacks. Hence there is an urgent need to devise mechanism to detect and eliminate optimistic SACK spoofing in SCTP and thereby make this promising protocol robust to SACK spoofing attacks.
Optimistic SACK spoofing in SCTP is relatively new and could be tactically exploited to constitute sophisticated attack scenarios. Its feasibility and associated threats were revealed during the year 2011 to 2012. To the best of our knowledge, there is no prior art for detection and elimination of optimistic SACK spoofing and associated DoS attacks in SCTP. Reference may be made to the prior art EP1463265B1 entitled “Method and apparatus for authenticating packet payloads via message authentication codes” dated January 2013, wherein it provides a method for authenticating packet payload via Message Authentication Code (MAC) to avoid malicious third party injecting or folding a false packet into a TCP connection. In that invention, the packet sending node computes a MAC of the packet based on a security key and a pseudo header with a pre-defined source and destination port fields and a pre-defined checksum value. The MAC is included as a part of the header of the packet being sent and the packet receiving node computes the MAC using the same secret key, pre-defined source and destination port fields and the predefined checksum value. If the two MAC values match, the packet is authenticated.
Reference may be made to another prior art EP2106095A1 entitled “Methods and device for enforcing network access control utilizing secure packet tagging”, dated September 2009 wherein it discloses a method and device for enforcing network access control using secure packet tagging. In that invention, a packet sending end-point computes a secure hash using a previously negotiated secret key and the content of the packet being sent. The hash is sent to the receiving end-point by including it in the identification field of the IP packet header. The receiver performs the hash calculation using the same secret key and received packet content, and accepts the packet only if the two hash values match.
In both the inventions mentioned above, the main drawback is that the MAC or hash embedded in the packet is derived from the packet that is being sent, and these inventions are suitable only to authenticate a packet, by the packet receiver, to the extent that it is neither modified nor generated by a malicious third party on the network. Said in other words, these inventions are intended to test and ensure that packets sent by one end-point reaches the other end-point intact. The packet authentication schemes disclosed in these inventions and other prior arts cannot detect or eliminate optimistic SACK spoofing in which the SCTP receiver itself (not a third party) is malicious, and the malicious action is to tactically generate acknowledgements (in the forms of SACK packets) before receiving the data to exploit the SCTP data sender for DoS flood generation.
For detection and elimination of maliciously spoofed optimistic SACKs, a drastically different approach than disclosed in the prior arts is necessary. In particular, the SCTP communication protocol needs to be enhanced with a feedback mechanism in which the SACK generator enriches its SACKs with appropriate additional information derived from the SCTP sender's data and the SCTP data sender needs robust mechanism to validate, using the feedback, that the SACK received from the SCTP data receiver has indeed been generated by the SCTP data receiver only after receiving the corresponding data. This need is addressed by various embodiments and configurations of the present invention.